home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1945 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.1 KB
  1. Path: news1.h1.usa.pipeline.com!usenet
  2. From: grantp@usa.pipeline.com(Pete)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: NT not written with MFC
  5. Date: 14 Jan 1996 11:27:02 GMT
  6. Organization: Kalevi, Inc.
  7. Message-ID: <4dapa6$4ef@news1.usa.pipeline.com>
  8. References: <30F76398.3A44@spider.compart.fi>
  9. NNTP-Posting-Host: pipe8.h1.usa.pipeline.com
  10. X-PipeUser: grantp
  11. X-PipeHub: usa.pipeline.com
  12. X-PipeGCOS: (Pete)
  13. X-Newsreader: Pipeline USA v3.3.0
  14.  
  15. On Jan 13, 1996 09:47:36 in article <Re: NT not written with MFC>, 'Anders
  16. Lindh <anders@spider.compart.fi>' wrote: 
  17.  
  18. Previous poster: 
  19. >> 1. The CDC class for device contexts was done very well and I find it 
  20. >> hard to believe that this was NOT used in writing the GUI for NT or 
  21. >> Windows 95. Did they not use it because they wanted to optimize it? 
  22. > 
  23. Anders: 
  24. >Uh, Microsoft has used MFC in some the applications that ship with Win95  
  25. >(e.g WordPad). A haven't botherd to look at MFC too much, but isn't MFC  
  26. >just a (easy to use and portable) wrapper around the Win(32) API ? I  
  27. >don't understand how they could have written the GUI with it, plain C++  
  28. >with assembly language gives much better performance.  
  29. > 
  30. Yes, MFC is a wrapper around Windows API; but many of those classes 
  31. do a lot of work for you and save time in development.  It's also 
  32. true that MFC invokes the execution of a lot of code to cover the 
  33. unusual rare cases and represents extra baggage for 99% of its 
  34. users.   
  35.  
  36. My observation is that MS isn't that concerned about performance 
  37. when it comes to end-user products.  I, therefore, can accept that 
  38. MFC was used for product development.  However, it is also very 
  39. easy to bypass MFC's code in time-critical apps and program 
  40. directly to the API -- I do it all the time.  I suspect that the final 
  41. product is a combination of MFC and direct API code. 
  42.  
  43. My reason for going 'behind' MFC is typically not speed, but to 
  44. attain behavior different from what MFC designers gave us.   
  45. (Sometimes it's just a case of not knowing how to accomplish the  
  46. task the MFC way and I take the easy way out.  I'm quite 
  47. comfortable with the windows API :-)) 
  48.  
  49. -- 
  50. Pete Grant 
  51. Kalevi, Inc. 
  52. Object Oriented Software Development
  53.